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Abstract 

A bidirectional transformation consists of a function get that takes 
a source (document or value) to a view and a function put that takes 
an updated view and the original source back to an updated source, 
governed by certain consistency conditions relating the two func¬ 
tions. Both the database and programming language communities 
have studied techniques that essentially allow a user to specify only 
one of get and put and have the other inferred automatically. All 
approaches so far to this bidirectionalization task have been syntac¬ 
tic in nature, either proposing a domain-specific language with lim¬ 
ited expressiveness but built-in (and composable) backward com¬ 
ponents, or restricting get to a simple syntactic form from which 
some algorithm can synthesize an appropriate definition for put. 
Here we present a semantic approach instead. The idea is to take a 
general-purpose language, Haskell, and write a higher-order func¬ 
tion that takes (polymorphic) ge/,-functions as arguments and re¬ 
turns appropriate put-functions. All this on the level of semantic 
values, without being willing, or even able, to inspect the definition 
of get, and thus liberated from syntactic restraints. Our solution 
is inspired by relational parametricity and uses free theorems for 
proving the consistency conditions. It works beautifully. 
Categories and Subject Descriptors D.3.3 [Programming Lan¬ 
guages ]: Language Constructs and Features—Data types and 
structures. Polymorphism; D. 1.1 [Programming Techniques]: Ap¬ 
plicative (Functional) Programming; D.2.4 [Software Engineer¬ 
ing ]: Software/Program Verification—Correctness proofs; F.3.1 
[Logics and Meanings of Programs ]: Specifying and Verifying 
and Reasoning about Programs; H.2.3 [Database Management ]: 
Languages—Data manipulation languages, Query languages 
General Terms Design, Languages, Verification 
Keywords generic programming, program transformation, view- 
update problem 

1. Introduction 

Imagine we have written the following Haskell function: 

halve :: [cc] —> [a] 

halve as = take (length as l div‘ 2) as 
Clearly, it outputs only an abstraction of its input list, as that list’s 
second half is omitted. Now assume this abstracted value, or view, 
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is updated in some way, and we would like to propagate this update 
back to the original input list. Here is how to do so: 
put, :: [a] - [a] - [a] 
put 1 as as' \ length as' == n 
= as' -H- drop n as 

where n = length as l div‘ 2 

Note that the backwards propagation of the assumed updated view 
as' into the original source as is only possible if as' is itself 
also half as long as as. This is so because otherwise there is no 
consistent way to combine as' and the second half of as into an 
updated source from which halve would indeed lead to as'. 

Let us consider another example; 

data Tree a = Leaf a | Node (Tree a) (Tree a) 

flatten :: Tree a —► [a] 
flatten (Leaf a) = [a] 
flatten (Node ti tf) = flatten ti -H- flatten £2 
Now the abstraction amounts to forgetting the tree structure of the 
input source. But if the list view is updated in any way preserving 
its length, the new content can be propagated back into the original 
tree as follows: 

put 2 ■■ Tree a —> [a] —> Tree a 
put 2 sv = case go s v of (t, []) t 
where go (Leaf a) (b : bs) = (Leaf b, bs ) 

go (Node si sf) bs = (Node t\ t2, ds) 
where (ti, cs) = go si bs 
(t 2, ds) = go S2 cs 

Finally, consider a function that removes duplicate occurrences 
of elements from a list, with implementation taken over from a 
standard library: 

rmdups :: Eq a =>■ [a] —> [a] 
rmdups = List.nufe 

An appropriate backwards propagation function looks as follows: 
put 3 :: Eq a =► [a] -*• [a] -*• [a] 

put 3 s v | t? =n= List. mt& v && length v == length s' 

= map (fromJust o flip lookup (zip s' v)) s 
where s' = List .nub s 
For example, in a Haskell interpreter: 

> put_3 "abcbabcbaccba" "aBc" 

"aBcBaBcBaccBa" 

Clearly, always having to explicitly write both forwards/back¬ 
wards-related functions is not the ideal situation. Thus, there has 
been a lot of recent research into bidirectionalization JHu et al.| 

| 2004[|Bohannon et al.l2006l|Foster et al.|2007l|Matsuda et al.|20071 

Bohannon et al. 2008, Foster et al. 2008). One approach is to de¬ 
sign a domain-specific language, fencing in a certain subclass of 






transformations, in which a single specification denotes both a for¬ 
ward and a backward function. Another approach is to devise an 
algorithm that works on a syntactic representation of (restricted) 
forward functions and tries to find the missing backward compo¬ 
nents. In this paper we present a completely novel approach that 
works for polymorphic functions such as those above. We write, 
directly in Haskell, a higher-order function bff (named for an ab¬ 
breviation of the paper’s title). This function takes a source-to-view 
function as input and returns an appropriate backward function. For 
example, we expect, and will get, 

bff halve s put 1 
bff flatten = put 2 
bff rmdups = put 3 . 

Note that applying bff to halve, for example, will not return the 
exact syntactic definition of put 1 given above, but merely a func¬ 
tional value that is semantically equivalent to it. Hence the use of 
= instead of = here. But this is absolutely enough from an applica¬ 
tion perspective. We want automatic bidirectionalization precisely 
because we do not want to be bothered with thinking about the 
backward function. So we do not care about its syntactic form, as 
long as the function serves its purpose. And the same level of syn¬ 
tactic ignorance applied to the input, rather than output, side of bff 
means that we can pass any Haskell function of appropriate type 
and obtain a good backward component for it. We are not restricted 
to drawing forward functions from some sublanguage only. 

Of course, the concept of a “good backward component” needs 
to be addressed. As evaluation criteria we use the standard con¬ 
sistency conditions ( |Bancilhon and Spyratos||T~981| that a for¬ 
ward/backward pair of functions get/put should satisfy the laws 

put s (get s) = s 
and, if put s v is defined, 

get (put sv) = v, 

known as GetPut and PutGet, respectively. These consistency con¬ 
ditions are why all the put -functions given above are partial func¬ 
tions only. For example, 

> put_3 "abcbabcbaccba" "aBB" 

should, and does, fail, because a view with duplicate elements can 
never be in the image of rmdups. An alternative that is used in 
some of the related literature would be to statically describe, or 
even calculate, the domain on which a put -function is well-defined, 
thus capturing a notion of permitted updates. We have not yet 
investigated whether this way of recovering totality is possible for 
our purely semantic approach to bidirectionalization. 

Even so, a natural question is how often a put-function obtained 
via bff will be undefined on some input. For example, a trivial put- 
function that is undefined whenever the v in put s v is not equal 
to get s would satisfy the GetPut and PutGet laws, but is clearly 
undesirable in practice. Our approach usually does better than that, 
but one significant limitation that it has in its current state is that any 
update that changes the “shape” of a view, say the length of a list, 
will lead to failure. Further discussion is contained in Section[7] 

Instead of a single function bff, we will actually give three 
functions bff, bffEq, and bfford, the choice from which depends on 
whether the source-to-view functions to be handled may involve 
equality and/or ordering tests on the elements contained in the 
data structures to be transformed. This reflects that for a function 
like rmdups conceptually more involved conditions are required 
for safe bidirectionalization than for halve or tail, or any other 
function of type [a] —> [a] without an Eq-constraint. So bffEq will 
be used for rmdups and its like, and fejfford for functions like the 


following one: 

top3 :: Ord a =>■ [a] —> [a] 

topS = take 3 o List, sort, o List.nufe 
But it is indeed the case that the single function bff applies to both 
halve and flatten, even though the former only deals with lists 
while the latter also involves trees. That is, bff, as well as bffEq and 
bff* brd, will be generic over both input and output structures. To get 
a rough idea of what kind of structures will be in reach, think of 
containers: shape plus data content (Abbott et al.|2003| . 

Proving that for any get a put obtained as bff get, bffEq get, or 
bff ,brd get satisfies the GetPut and PutGet laws will be done by us¬ 
ing free theorems (Reynolds] 1983t|Wadler|1989fr . Our formal rea¬ 
soning there will be “morally correct” in the sense of |Danielsson| 
|et al. |(2006) . That is, our proofs of the GetPut and PutGet laws will 
apply to total get-functions and total, finite data structures. In par¬ 
ticular, we do not take into account Haskell intricacies like those 
studied by | Johann and Voigtlander| (2004) . This simplification is 
done solely for the sake of exposition, not because of any funda¬ 
mental problems with doing elsewise. 

All code in this paper was developed and tested using the Glas¬ 
gow Haskell Compiler 6.8.2. The final, generic version of the code 
is available as Hackage (http: //hackage .haskell. org) pack¬ 
age bf f-0.1 An online tool based on it is also available at http: 
//linux.tcs.inf.tu-dresden.de/~bff/cgi-bin/bff.cgi 
Throughout, we sometimes use common Haskell functions and 
types without further comment, like fromJust, lookup (and thus 
Maybe), and zip above. Where these are not clear, Hoogle (http: 
//haskell. org/hoogle) has the answer. 

2. Getting Started 

We first deal only with lists as both input and output structures, 
aiming at a bidirectionalizer of type 

bff :: (Va.[a] -> [a]) -> (Va.[a] -> [a] -> [a]). 

Note that the local universal quantifications over a are essential 
here, and require compiler flag -XRank2Types. 

Now, how can bff possibly learn anything about its input func¬ 
tion, so as to exploit that information for producing a good back¬ 
ward function? The idea is to use the assumption that the input 
function get is polymorphic over the element type a. This entails 
that its behavior does not depend on any concrete fist elements, 
but only on positional information. And this positional information 
can even be observed explicitly, for example by applying get to 
ascending fists over integer values. Say get is tail, then every list 
[0..n] is mapped to [l..n], which allows bff to see that the head 
element of the original source is absent from the view, hence can¬ 
not be affected by an update on the view, and hence should re¬ 
main unchanged when propagating an updated view back into the 
source. And this observation can be transferred to other source fists 
than [0..n] just as well, even to lists over non-integer types, th anks 
to parametric polymorphism (Strachey 1 1967] [Reynolds11983) . 

Let us develop this line of reasoning further, still on the tail 
example. So bff tail is supposed to return a good put. To do so, 
it must determine what this put should do when given an original 
source s and an updated view v. First, it would be good to find 
out to what element in s each element in v corresponds. Assume 
s has length n + 1. Then by applying tail to the same-length list 
[0..n], bff (or, rather, bff tail = put ) learns that the original view 
from which v was obtained by updating had length n, and also to 
what element in s each element in that original view corresponded. 
Being conservative, we will only accept v if it has retained that 
length n. For then, we also know directly the associations between 
elements in v and positions in the original source. Now, to produce 
the updated source, we can go over all positions in [0..n] and fill 














fromAscList :: [(Int, cc)] —> IntMap a 

empty :: IntMap a 

notMember :: Int —> IntMap a —► Bool 

insert :: Int —► a —> IntMap a —> IntMap a 

union :: IntMap a —> IntMap a —> IntMap a 

lookup :: Int —► IntMap a —* Maybe a 


Figure 1 . Functions from module Data.IntMap. 


them with the associated values from v. For positions for which 
there is no corresponding value in v, because these positions were 
omitted when applying tail to [0..n], we can look up the correct 
value in s rather than in v. For the concrete example, this will 
only concern position 0, for which we naturally take over the head 
element from s. 

The same strategy works also for general bJJ get. In short, 
given s, produce a kind of template s' = [0..n] of the same 
length, together with an association g between integer values in 
that template and the corresponding values in s. Then apply get to 
s' and produce a further association h by matching this template 
view versus the updated proper value view v. Combine the two 
associations into a single one h!, giving precedence to h whenever 
an integer template index is found in both h and g. Thus, it is 
guaranteed that we will only resort to values from the original 
source s when the corresponding position did not make it into the 
view, and thus there is no way how it could have been affected 
by the update. Finally, produce an updated source by filling all 
positions in [0..n] with their associated values according to h'. 
For maintaining the associations between integer values and values 
from s and v, we use the standard library Data. IntMap. Concretely, 
we import from it the functions given in Figure |T| Their names 
and type signatures should be enough documentation here, the only 
necessary additions being that \ntN\ap.fromAscList expects a list 
with integer keys in ascending order and that IntMap. union is 
left-biased for integers occurring as keys in both input maps. The 
latter will precisely realize the desired precedence of h over g. The 
described strategy is now easily implemented as follows: 
bff :: (Va.[a] - [a]) - (Va.[a] - [a] - [a]) 
bff get = As v —> 
let s' = [0 ..length s — 1] 

g = intMap.fromAscList (zip s' s) 
h = assoc (get s') v 
b! = IntMap. union h g 
in map (JromJust o flip IntMap. lookup h') s' 

assoc :: [Int] —► [a] —> IntMap a 
assoc [] [] = IntMap. empty 

assoc {i : is) (b : bs) | IntMap. notMember i m 
= IntMap .insert ibm 
where m = assoc is bs 

Note that the function assoc, realizing the matching between the 
template view and the updated proper value view, needs to check 
that no index position is encountered twice, because otherwise it 
would not (yet) be clear how to deal with two potentially different 
update values. 

Our current version of bff works quite nicely already. For ex- 

> bff tail "abed" "bCd" 

"abCd" 


we automatically get 

> bff sieve "abedefg" "123" 

"alc2e3g" 

(Note that sieve “abedefg” = “bdf”.) 

However, ultimately the current version is too weak. It fails as 
soon as a source-to-view function duplicates a list element. For 
example, 

> bff (\s -> s ++ s) "a" "aa" 

fails, defeating the GetPut law. (Note that the GetPut law would 
demand that bff (As —> s -H- s) “a” ((As —► s -H- s) “a”) = “a”.) 
And also, a bit more subtly, the PutGet law is violated for empty 
source lists: 

> bff halve "" "a" 


(Note that the PutGet law would demand that, if bff halve “a” is 
defined, halve (bff halve “a”) = “a”, but it is not the case that 

On the other hand, apart from this empty list weirdness we truly 
have bff halve = pul ,. So it seems we have made a good start, on 
which to extend in the next section. 

3. Correct Bidirectionalization 

In order to fix bff to adhere to the GetPut law, we need to deal 
with duplication of list elements. Consider again the source-to-view 
function As —> s-H-s, Applied to a template [0..n], it will de¬ 
liver the template view [0,..., n, 0,..., n]. Under what conditions 
should a match between this template view and an updated proper 
value view be considered successful? Clearly only when equal in¬ 
dices match up with equal values, because only then we can pro¬ 
duce a meaningful association reflecting a legal update. 

However, equality tests are not possible in Haskell at arbitrary 
types. So we will have to weaken the type of bff as follows: 
bff :: (V«.[«] - [a]) - (Va. Eq a =► [a] =♦ [a] -> [a]) 

That is, the pet-function given to bff will still (have to) be fully 
polymorphic, but the returned put-function will only be applicable 
to lists over an element type satisfying the Eq-constraint. This is 
not expected to cause any problems in practice, because applica¬ 
tion scenarios for view-update will typically involve data domains 
for which equality tests are naturally available (as opposed to, say, 
operating on lists of functions). And in any case, we could always 
recover the law-wise weaker but also type-wise slightly wider ap¬ 
plicable version of bff from the previous section by simply defin¬ 
ing bogus instances of Eq where the equality test == invariably 
returns False. 

Armed with equality tests, we can rewrite the function assoc 
as follows. We also take the opportunity to introduce more useful 
error signaling than pattern-match errors as implicitly used before. 

assoc :: Eq a => [Int] —► [a] —► Either String (IntMap a) 

assoc [] [] = Right IntMap. empty 

assoc (i : is) (b : bs) = either Left ( checklnsert i b) 

(assoc is bs) 

assoc = Left “Update changes the length.” 

checklnsert :: Eq a => Int —> a —> IntMap a 

—> Either String (IntMap a) 

checklnsert ibm = 

case IntMap. lookup im of 
Nothing —> Right (IntMap. insert ibm) 

Just c —> if b == c 

then Right m 

else Left “Update violates equality.” 


e :: [a] - [a] 
e (a : b : cs) = b 



From now on, we assume that every instance of Eq gives a 
definition for == that makes it reflexive, symmetric, and transitive. 
Then, the following two lemmas hold. 

Lemma 1. For every is :: [Int], type r that is an instance of Eq, 
and f :: Int —> r, we have 

assoc is (map f is) = Right h 
for some h :: IntMap r with 

\t\tMap.lookup i h = if elem i is then Just (/ i) else Nothing 
for every i :: Int. 

Lemma 2. Let is :: [Int], let r be a type that is an instance of Eq, 
and letv :: [r] and h :: IntMap r. We have that if 

Right h = assoc is v , 


map (flip IntMap .lookup h) is == map Just v. 

We do not explicitly prove either of the two lemmas here. Both 
are easily established by induction on the list is, taking the spec¬ 
ifications of functions in Data.IntMap into account. Note that in 
the conclusion of Lemma |2l we cannot simply replace == by =, 
because the instance of Eqfor r may very well give x == y for 
some x ^ y. We will continue to be careful about this distinction 
in what follows. Of course, the instances of Eq used in practice 
will often have == agree with semantic equivalence (such as for 
integers, characters, strings,...). 

The improved version of assoc can now be used for an im¬ 
proved version of bJJ as follows: 

bff :: (V«.[«] - [a]) - (Va. Eq a ^ [a] - [a] [a]) 

bff get = A s»—> 
let s' = [0.. length s — 1] 

g = IntMap .fromAscList (zip s' s) 
h = either error id (assoc (get s') v) 
h 1 = IntMap .union h g 

in seq h (map (fromJust o flip IntMap .lookup h') s') 

Note that the use of error turns a potential failure in assoc (or, 
via assoc, in checklnsert) into an explicit runtime error with 
meaningful error message. The use of seq prevents such an error 
going unnoticed in the case that s, and thus s', is the empty list. 
(This solves the problem with the PutGet law observed at the end 
of Section[2]) Instead of the polymorphic strict evaluation primitive 
we could also have used an emptiness test or any other strict 
operation on h. 

The new version of bff now does not only work for halve, tail, 
sieve, and the like, but also for get-functions that duplicate list 
elements. For example, 

> bff (\s -> s ++ s) "a" "aa" 

> bff (\s -> s ++ s) "a" "bb" 

"b" 

> bff (\s -> s ++ s) "a" "ab" 

"*** Exception: Update violates equality. 

Formally, we establish the GetPut and PutGet laws as follows. 


Theorem 1. For every function get :: Vq.[q] —> [a], type t 
that is an instance of Eq, and s :: [r], we have 
bff get s (get s) s s. 


Proof. By the function definition for bff we have 
bff get s (get s) 

seq h (map (fromJust o flip IntMap .lookup h') s') , 


( 1 ) 




s' = [0.. length s - 1] (2) 

g = \ntMap. fromAscList (zip s' s) (3) 

h = either error id (assoc (get s') (get s)) (4) 

h' = IntMap. union h g. (5) 

Clearly, |2]l implies 

s S map (s !!) s', (6) 

where the operator !! is used for extracting a list element at a given 
index position. Thus, 

get s = get (map ( s !!) s'). 

By a free theorem of | Wadler|41989| >, every get :: Va.[a] —> [a] 
satisfies 

get o map f = map f o get 
for every choice of /. Thus, in particular, 

get s = map (s !!) (get s'). 

Together with |4| and Lemma [l] this gives that h is defined (i.e., 
not a runtime error) and that for every i :: Int, 

IntMap. lookup i h = if elem i (get s') then Just (s !! i) 
else Nothing. 

Since by 0.0- and the specification of IntMap, fromAscList, 
for every i :: Int, 

IntMap. lookup i g = if elem i s' then Just ( s !! i) 
else Nothing, 

we have by ([5J and the specification of IntMap. union that for 
every i :: Int, 

IntMap. lookup i h = if elem i (get s') 
then Just (s !! *) 

else if elem i s' then Just (s!! *) 
else Nothing. 

Together with |lj, the definedness of h, and |6|, this gives the claim. 


Theorem 2. Let get :: Va.[a] —> [a], let t be a type that is an 
instance of Eq, and let v , s :: [t]. We have that if bff get s v 
is defined, then 

get (bff get s v) == v. 


The proof of this second theorem, relying on Lemma [2] and using 
a similar style of reasoning as above, is given in Appendix [A] 
Note that the theorem establishes the PutGet law only up to ==, 
rather than for true semantic equivalence. As mentioned earlier, in 
practice == will typically agree with 3 for the types of data under 
consideration, so this is no big issue. 


4. Source-to-View Functions with Equality Tests 

In the previous section we already used Eq-constraints for deliver¬ 
ing good pwt-functions. On the other hand, the get-functions taken 
as input had to be fully polymorphic, and for good reason. Tempt¬ 
ing as it may be to simply change the type of bff to 


bff :: (Va. Eq a ^ [a] 
-> (Va. Eq a [ 


N), 




so that it would also accept jet-functions like the rmdups :: 
Eq a => [a] —► [a] from the introduction, this would be inviting 
disaster: 

> bff rmdups "abcbabcbaccba" "aBc" 

"*** Exception: Update changes the length. 

> bff rmdups "abcbabcbaccba" "abc" 

"*** Exception: Update changes the length. 

> bff rmdups "abc" "aaa" 

> bff rmdups "aaa" "abc" 

All four experiments disagree with our expectations. For exam¬ 
ple, since rmdups “abcbabcbaccba” = “abc”, we would have ex¬ 
pected in the first experiment that a view update into “aBc” leads 
to an update of the source into “aBcBaBcBaccBa”. But instead, 
bff rmdups fails. In the second experiment, where the view “abc” 
has not even been changed at all, we would have expected that 
bff rmdups returns the original source “abcbabcbaccba”. After all, 
that is what the GetPut law demands. But it does not happen. Sim¬ 
ilarly, the third experiment violates the PutGet law. 

The main reason for failure here is that it is not necessarily 
true that one can always understand the behavior of a function 
get :: Eq a =4> [a] —> [a] on a source list s by simply ob¬ 
serving its behavior on the template list [0..n] of the same length. 
For this would completely lose track of potentially duplicated el¬ 
ements in s and how get might react to them. Note that this issue 
is nonexistent in Section [3] because a fully polymorphic function 
get :: [a] —> [a] is unable to react to duplicated elements, as it 
cannot even detect them. Since here this is different, the first step to¬ 
wards a solution is a more intelligent template manufacture. For ex¬ 
ample, instead of [0..12] the template for “abcbabcbaccba” should 
be [0,1,2,1,0,1,2,1,0, 2,2,1,0], together with an association of 
0 to ‘a’, 1 to ‘b’, and 2 to ‘c’. In writing a function to do this job, 
one needs to keep track of which elements have already been seen 
while going through the source fist. Thus, it makes sense to use a 
state monad ( |Wadler|1992[ l. And since for every element already 
seen one needs to be able to determine the template integer value to 
which it has been associated, it makes sense to extend the IntMap 
abstraction with a facility for “backwards” lookup. We have imple¬ 
mented such a new abstraction, with API as given in Figure [2] Of 
immediate interest here are only the functions IntMapEq. emptj, 
IntMapEq.insert, and IntMapEq .lookupR. Using them, we ob¬ 
tain the following piece of code. The state that is carried around 
consists of an IntMapEq containing the elements that have already 
been encountered and an integer denoting the next available key. 
The function numberEq describes the action to be performed for 
every element found in a source list, and by which integer key to 
replace it in the template list. 

template E q :: Eq a =$■ [a] —*■ ([Int], IntMapEq a) 
template E q s = case runState (go s ) (IntMapEq. empty, 0) 
of (»',(>,_}) (s',g) 
where go [ ] as return [ ] 

go (a : as) = do i <— numberEq a 
is <- go as 
return (i : is) 

numberEq :: Eq a => a —> State (IntMapEq a, Int) Int 
numberEq a = 
do (m, i) <— State, jet 

case IntMapEq.Zoofcwp-R am of 
Justj —> return j 

Nothing —> do let m' = IntMapEq. insert i am 
State. put (m 1 , i + 1) 
return i 


empty :: IntMapEq a 

insert :: Int —> a —> IntMapEq a —> IntMapEq a 

checklnsert :: Eq a =>- Int —> a —*■ IntMapEq a 

—> Either String (IntMapEq a) 
union :: Eq a =>■ IntMapEq a —> IntMapEq a 

—► Either String (IntMapEq a) 
lookup :: Int —> IntMapEq a —> Maybe a 

lookupR :: Eq a => a —> IntMapEq a —> Maybe Int 


Figure 2. Functions from module IntMapEq. 


Then, for example, 

> template_Eq "transformation" 

([0,1,2,3,4,5,6,1,7,2,0,8,6,3].fromList [(0,’t’),( 
l,’r , ),(2,’a’),(3, , n’),(4,’s’),(5, , f , ),(6, , o’),(7, 
’m’),(8,’i’)]) 

More generally, the following lemma holds. 

Lemma 3. Let t be a type that is an instance of Eq and let s :: [r], 
s' :: [Int], and g :: IntMapEq r. We have that if 
( s' ,g) = template E q s, 

• map (flip IntMapEq. lookup g) s' == map Just s, 

• for every i :: Int not in s', IntMapEq. lookup i g = Nothing, 

• for every i/= j ins', 

IntMapEq. lookup i g /= IntMapEq. lookup j g. 

Here /= is the complement of ==. Again we refrain from giving 
an explicit proof of this auxiliary lem ma. It is quite similar to an 
example of |Hutton and Fulg~er| ( [2008) , and we have nothing con¬ 
ceptually new to contribute right here regarding proof techniques. 

The final statement in Lemma [3] about different integers being 
mapped to different (according to /= at type r) values by j is very 
essential. The proofs of both Theorems[l]and[2]use the free theorem 
get o map f = map f o get. But that was for get :: [a] —> [a]. For 
the get :: Eq a =► [a] —> [a] of interest now, we know from 
|Wadler| ( [19891 Section 3.4) that / cannot be arbitrary anymore. 
Rather, it must respect Eq in the sense that x == y if and only 
if / x / y. And since ultimately the / for which we will 
want to apply the free theorem are connected to j and later h', 
we need an injectivity invariant for the Int Map Eqs under use. This 
is why both IntMapEq .checklnsert and IntMapEq. union have 
Either String (IntMapEq a) as return type in Figurejj] so that they 
can give a meaningful error message in case of a violation of this 
invariant. The IntMapEq. insert used in numberEq, on the other 
hand, has no such safeguards. But Lemma[3]tells us that everything 
is still okay with template E q . 

Of course, we also need to adapt assoc, but only slightly. 
Basically, we just switch from operations on IntMaps to op¬ 
erations on IntMapEqs, the most important change being that 
IntMapEq. checklnsert does not only prevent insertion of two dif¬ 
ferent update values for the same integer key, but does also prevent 
insertion of equal update values for different integer keys (so as 
to prevent the bff rmdups “abc” “aaa” = “aaa” disaster with its 
violation of the PutGet law). The variant of assoc to use is then as 
follows: 

assoc Eq :: Eq a =>■ [Int] —> [a] —> Either String (IntMapEq a) 
assocEq [] [] = Right IntMapEq. empty 

assocEq (i : is) (b : bs) = either Left 

(IntMapEq. checklnsert i b) 
(assocEq is bs) 

assoc Eq = Left “Update changes the length.” 








For it, we claim the following two lemmas. The notion of a function 
/ :: Int —> r, for a type r that is an instance of Eq, being 
injective on a list is :: [Int] is defined as “for every i f—j in is. 

Lemma 4. Let is :: [Int], let r be a type that is an instance of Eq, 
and let f :: Int —> r and v :: [r]. We have that if map f is == v 
and f is injective on is, then 

assocEq isv= Right h 
for some h :: IntMapEq r with 

IntMapEq.(oofcwp i h == if elem i is then Just (/ i) 
else Nothing 

for every i :: Int. 

Lemma 5. Let is :: [Int], let t be a type that is an instance of Eq, 
and letv :: [r] and h :: IntMapEq r. We have that if 
Right h = assocEq is v, 

then 

• map (flip IntMapEq. lookup h) is == map Just v, 

• for every i :: Int notin is, IntMapEq. lookup ih = Nothing, 

• flip IntMapEq. lookup h is injective on is. 

Like for Lemmas [l] and [2] the proofs are by induction on the 
list is, hut now relying on the correct implementation (in particular, 
regarding the injectivity invariant) of the operations in module 
IntMapEq. 

Now we are prepared to give a correct bidirectionalizer for 
source-to-view functions potentially involving equality tests: 
bffEq :: (Va. Eq a =► [a] -» [a]) 

-(Va. Eq a =>■ [a] —*• [a] —*■ [a]) 
bjfE q get = As v —► 
let (s',g) = template E q s 

h = either error id (assoc E q (get s') v) 
h! = either error id (IntMapEq. union h g) 
in seq h' (map (fromJust o flip IntMapEq. lookup h') s') 
Let us do some sanity checks: 

> bff_Eq rmdups "abcbabcbaccba" "aBc" 
"aBcBaBcBaccBa" 

> bff_Eq rmdups "abcbabcbaccba" "abc" 
"abcbabcbaccba" 

> bff_Eq rmdups "abc" "aaa" 

"*** Exception: Update violates differentness. 

> bff_Eq rmdups "aaa" "abc" 

"*** Exception: Update changes the length. 

This looks much better than what we saw at the beginning of the 
current section. Indeed, we now truly have bffEq rmdups = put 3 
for put 3 as given in the introduction (except that bffEq rmdups 
gives more meaningful error messages). 

A small, but important, detail in the definition of bffEq is that 
the computation of h! via IntMapEq. union may now also lead to 
an error being raised. This is essential for properly dealing with 
examples like the following one: 

> bff_Eq (tail . rmdups) "abcbabcbaccba" "ba" 

"*** Exception: Update violates differentness. 

Note that the view obtained from “abcbabcbaccba” by applying 
tail o rmdups is “be”. Updating “be” to “ba” does not yet introduce 
a differentness violation on the view level. But blindly propagating 
this change from ‘c’ to ‘a’ back into the original source would give 
“ababababaaaba”. And this would contradict the PutGet law, be¬ 
cause tailormdups applied to “ababababaaaba” gives “b”, which is 


different from the supposed “ba”. The solution employed to detect 
such late conflicts (arising when the updates learned by comparing 
the template view with the updated proper value view encounter 
those values from the original source that did not make it into the 
view and thus are simply kept unchanged) is to make sure that no 
unwarranted equalities occur when combining the associations h 
and g into h!. Our implementation of IntMapEq. union takes care 
of that. This does not change its left-biased nature. That is, an error 
is only reported if a pair (i, b) in h conflicts with a pair ( j, a) in g 
in the sense that a == b and there is no pair (j, c) in h that renders 
(j, a) irrelevant. 

Before proving the GetPut and PutGet laws for bffEq, let us 
clarify the situation of free theorems for functions of the type 
get :: Va. Eq a =>■ [a] —> [a]. The general form, as obtained for 
example from our online free theorems generator http: //linux. 
tcs.inf.tu-dresden.de/~voigt/ft is that for every choice 
of types n and ti that are instances of Eq, relation 1Z between 
them that respects Eq, and lists l\ ■■ [n] and h :: [rf) of the same 
length and element-wise related by 1Z, the lists get 1 1 and get I.2 are 
also of the same length and element-wise related by 1Z. The notion 
of 1Z respecting Eq here means that for every (a, b) and (c, d) in 7Z, 
a == c if and only if b » d. This general free theorem easily 
gives the following specialized version. 

Lemma 6. Let get :: Va. Eq a => [a] —> [a], let t be a type 
that is an instance of Eq, and let f :: Int —► r, s' :: [Int], and 
s :: [r]. We have that if map f s' == g and f is injective on s', 
then map f (get s') == get s and every i in get s' is also in s'. 
The relation 1Z used for this specialization is the one which contains 
exactly all pairs (i , a) with i ::: lint, a :: r, i in s', and / i == a. 

Now, we can go about proving the GetPut and PutGet laws for 
bffEq. The former is now also established only up to ==. 


Theorem 3. For every get :: Va. Eq a => [a] —> [a], type t 
that is an instance of Eq, and s :: [r], we have 
bffEq get s (get s)== s. 


Theorem 4. Let get :: Va. Eq a =>■ [a] —> [a], let t be a 
type that is an instance of Eq, and let v,s :: [r]. We have that 
if bffEq get s v is defined, then 

get (bffEq get sv) ==v. 


The proofs of these two theorems, relying on Lemmas [3}|6] are 
given in Appendices[B]and[C] 

5. Source-to-View Functions with Ordering Tests 

Having dealt with equality tests, how about ordering tests? Can we 
produce a correct bidirectionalizer of type 

Word :: (Va. Ord a =► [a] - [a]) 

—> (Va. Ord a [a] —> [a] —► [a]) ? 

The roadmap to follow should be relatively clear from the previous 
section. First, we need an appropriate template manufacture. Now 
the template integer values should not only reflect which elements 
in the original source are equal, but also need to reflect their rel¬ 
ative order. Since this means that we cannot assign integer values 
until we have seen the full source list, it turns out that the “monadic 
traversal” used in template E q is not sufficient anymor e. Instead, we 
use the framework of applicative functors, or idioms ( |McBride and| 







|Paterson|2008[ >. It is captured by the following Haskell type con¬ 
structor class, defined in the standard library Control.Applicative: 
class Functor (j> => Applicative 4> where 

pure :: a —*■ a 

(<*>) ::0(a->/?)->^a->0/? 

For ordered template generation we conceptually need two phases, 
a first to collect all values occurring in the original source list, 
so that after sorting them a second phase can assign appropriate 
integer values. It turns out that for both tasks there already exist 
predefined applicative functors. For the collection of values, we 
can simply use the constant functor (Control.Applicative.Const) 
mapping to the monoid (Data.Monoid) of sets (Data.Set): 
collect :: Ord a =4- [a] —> Const (Set a) [/3] 
collect s = traverse (A a —> Const (Set. singleton a)) s 

traverse :: Applicative => (a —> [J) —> [a] —> cf> \/3] 
traverse f [] = pure [] 

traverse f (a : as) = pure (:) <*> / a <*> traverse f as 
To build a proper association between integer values and (ordered) 
source values, we need an abstraction similar to IntMapEq but 
maintaining an order-preservation invariant as well. We provide 
this in module IntMapOrd, with API as given in Figure [3] Note 
that fromAscPairList expects a list with both keys andvalues 
in ascending order. Together with the function Set .toAscList that 
transforms a set into a sorted list, we can define 
set2map :: Ord a =>■ Set a —> IntMapOrd a 
setSmap as = 

IntMapOrd .fromAscP air List (zip [0..] (Set. toAscList as)) 
and then have, for example: 

> set2map . getConst $ collect "transformation" 
fromList [(0,’a’),(l,’f’),(2,’i’),(3,’m’),(4,’n’), 
(5,»o').(6,*r*),(T,*B*).(8,'t»)] 

For propagating knowledge about such a proper assignment be¬ 
tween integer values and ordered source values, we can use a par¬ 
tially applied function arrow functor^ 

propagate :: Ord a =>■ [a] —> ((—►) (IntMapOrd a)) [Int] 
propagate s = 

traverse (A a —► fromJust o IntMapOrd .lookupR a) s 

For example, with m being the IntMapOrd Char returned above, 

> propagate "transformation" m 
[8,6,0,4,7,1,5,6,3,0,8,2,5,4] 

Since we do not want to spend two traversals on the collection 
and propagation phases, we pair the involved applicative functors 
together with a lifted product bifunctor. Altogether, we realize the 
new template generator as follows: 
templateord :: Ord a =>■ [a] —> ([Int], IntMapOrd a) 
templateord s = case traverse numberord s of 

Lift (Const as, f) —> let m = set2map as 

in (/ m, m) 

numberord :: Ord a => a —> Lift (,) (Const (Set a)) 

((—►) (IntMapOrd a)) Int 
numberord a = Lift (Const (Set .singleton a), 

fromJust o IntMapOrd .lookupR a) 

Note that number o r d, which serves as argument to traverse in 
the definition of templateord, is essentially obtained as a “split” 


1 Note that the type of propagate could equivalently be written as follows: 
Ord a =>- [a] —> IntMapOrd a —> [Int], 


fromAscP air List :: Ord a =4- [(Int, a)] —» IntMapOrd a 

empty :: IntMapOrd a 

checklnsert :: Ord a => Int —> a —> IntMapOrd a 

—> Either String (IntMapOrd a) 
union :: Ord a IntMapOrd a —> IntMapOrd a 

—> Either String (IntMapOrd a) 
lookup :: Ord a =*- Int —> IntMapOrd a —> Maybe a 

lookupR :: Ord a => a —> IntMapOrd ol —> Maybe Int 


Figure 3. Functions from module IntMapOrd. 


of the corresponding arguments in the definitions of collect and 
propagate above. This kind of tu pling is an old tric k to avoid mul¬ 
tiple traversals of data structures < |Pettorossi11987[ . An alternative 
approach to ordered template generation would be to use an order- 
maintenance data structure ( [Dietz and Sleator| 1987} . 

Under the assumption that in addition to the conditions we have 
already imposed on instances of Eq every instance of Ord satisfies 
that the provided < is transitive, that x < y implies x /= y, and 
that x /=y implies x < y or y < x, the following analogue of 
Lemma[3]now holds. The notion of a function / :: Int —> r, for a 
type r that is an instance of Ord, being order-preserving on a list 
s' :: [Int] is defined as “for every i < j in s', also f i < f j”. 
Lemma 7 . Let t be a type that is an instance of Ord and let 
s :: [t], s' :: [Int], and g :: IntMapOrd r. We have that if 

( s' ,g) = templateord s, 

then 

• map (flip IntMapOrd.ioofcup g) s' == map Just s, 

• for every i :: Int not in s', IntMapOrd. lookup i g = Nothing, 

• flip IntMapOrd. lookup g is order-preserving on s'. 

We omit a formal proof, but the following example should be 
reassuring: 

> template_0rd "transformation" 

([8,6,0,4,7,1,5,6,3,0,8,2,5,4].fromList [(0,’a’),( 
l,’f’),(2,’i , ),(3,’m’),(4,’n’),(5, , o’),(6, , r'),(7, 
*sO.(8,*t»)]) 

On the view association side, the changes from assocEq to 
assoc ord are almost trivial: 

assoco,d ■■■ Ord a =>• [Int] —► [a] —> Either String (IntMapOrd a) 
assoc ord [] [] = Right IntMapOrd.empty 

assoc ord (* : is) (b : bs) = either Left 

(IntMapOrd. checklnsert i b) 
(assocord is bs) 

assoc ord - - = Left “Update changes the length.” 

and analogues of Lemmas [4] and Bl for assoc o r d instead of assoc.E q 
are obtained by simply replacing Eq by Ord, “injective” by “order¬ 
preserving”, and IntMapEq by IntMapOrd. 

Finally, our bidirectionalizer for source-to-view functions po¬ 
tentially involving ordering tests takes the following, by now prob¬ 
ably expected, form: 
bffo rd :: (Vq. Ord a => [a] -*• [a]) 

—> (Va. Ord a => [a] —> [a] —> [a]) 

bfford get — As V > 

let {s',g) = templateord s 

h, = either error id (assocord (get s') v) 
h! = either error id (IntMapOrd. union hg) 
in seq h! (map (fromJust ° flip IntMapOrd. lookup h') s') 
Showing off its power, for the function topS from the introduction: 










> bff_Ord top3 "transformation" "abc" 
"transbormatcon" 

> bff_0rd top3 "transformation" "xyz" 

"*** Exception: Update violates relative order. 

For proving the GetPut and PutGet laws for ftjfford. we need 
an appropriate free theorem that holds for every function of type 
get :: Va. Ord a => [a] —► [a]. Again consulting the online free 
theorems generator http: //linux. tcs. inf. tu-dresden. de/ 
~voigt/f t, we obtain that for every choice of types n and T2 that 
are instances of Ord, relation 1Z between them that respects Ord, 
and lists li :: [n] and h :: [75] of the same length and element¬ 
wise related by 1Z, the lists get 1 1 and get h are also of the same 
length and element-wise related by 7 Z. The notion of 7 Z respecting 
Ord here means that for every (a, b) and (c, d) in TZ, a < c if and 
only if b < d (and assuming that the other operations of the Ord 
type class relate to the definitions for == and < in the natural way). 
Setting n = Int, T2 =t,7Z = {(*, a) \ elem i s' && / i == a}, 
li m s', and I2 = s, we obtain the following specialized version. 
Lemma 8. Let get :: Va. Ord a =4- [a] —> [a], let r be a type that 
is an instance of Ord, and let f :: Int —► r, s' :: [Int], and s :: [t]. 
We have that if map f s' == s and f is order-preserving on s', 
then map f (get s') == get s and every i in get s' is also in s'. 

Now, quite pleasingly, the proofs of the following two theorems 
are exact replays of the proofs given for Theorems [3| an d [4] in 
Appendices [B] and|C] respectively, except that Lemma |7] is used 
instead of Lemma [3j that Lemma [8] i s used instead of Lemma [6] 
and that the analogues of Lemmas]?] and [5] mentioned above are 
used instead of those two lemmas themselves. 


Theorem 5. For every get :: Va. Ord a => [a] —► [a], type t 
that is an instance of Ord, and s :: [r], we have 

bff< ord get s (get s) == s. 


Theorem 6. Let get :: Va. Ord a =>■ [a] —* [a], let r be a 
type that is an instance of Ord, and let v,s :: [r]. We have 
that if bjford get s v is defined, then 

get (bfford get sv) == v. 


6. Going Generic 

So far, we have focused on list data structures for sources and 
views. In this section, we lift this restriction, both on the input and 
output sides of get -functions. Let us start with the input side, and 

With bjford . 

Where in the definition of bJJo,d is the fact important that the 
input data structure is a list? The answer is: at two places; once 
in the definition of traverse as used in templateorA and thus in 
bjj< brd, and once when using map inside bJ]o,d itself. But note that 
even though we have provided our own definition of traverse in 
the previous section, a function with that name already exists in the 
standard library Data.Traversable, where it is a method of the type 
constructor class Traversable and has the following type: 
traverse :: (Applicative 4>, Traversable k) 

=>■ (a -► 4> p) -► k a -► 4 > (k 0 ) . 
Moreover, there is also a predefined instance of Traversable for 
the type of lists, and the definition for traverse in that instance 
is exactly the one seen in the previous section. So we could have 


avoided defining our own traverse and instead used the predefined 
one. But more importantly, we can give template o r d the following 
more general type, without changing anything about its definition: 
templateorA :: (Traversable k, Ord a) 

=4> /t a —> (« Int, IntMapOrd a). 
Providing an instance definition for the data type Tree from the 
introduction as follows: 

instance Traversable Tree where 
traverse f (Leaf a) = pure Leaf <*> / a 
traverse f (Node ti ti) = pure Node <*> traverse f ti 
<*> traverse f ti 

we then have, for example: 

> template_Ord (Node (Leaf ’a’) (Leaf ’b’)) 

(Node (Leaf 0) (Leaf l),fromList [(0,’a’),(1,’b’)]) 
Actually, for dependency reasons, we also need to add the follow¬ 
ing two instance definitions: 

instance Foldable Tree where 
foldMap = foldMap Default 
instance Functor Tree where 
fmap = fmapDefault 

But these will always he the same for every new data type, and 
so do not impose any real burden. And even the burden of hav¬ 
ing to write Traversable instances can be avoided. Namely, by us¬ 
ing the modules Data.DeriveTH and Data.Derive.Traversable of 
Hackage package derive-0.1.1 (authored by N. Mitchell and S. 
O’Rear), as well as compiler flag -XTemplateHaskell, we could 
instead of the above manual instance definition for Tree simply 
have written 

$( derive makeTraversable ''Tree ) 

Back to &iford itself. Since every Traversable is also a Functor, 
it now suffices to replace map by 

fmap :: Functor k=^(/3—> a) —► «« a 
in fyfford’s definition to allow a generalization of its type as well: 
bfford ■■■ Traversable k => (Va. Ord a =>• « a —> [a]) 

—> (Va. Ord a4sa->[a|-t«a). 
This means that we can now bidirectionalize functions of type 
get :: Va. Ord a n a —> [a] for any instance n of Traversable, 
not just for lists. For example, we can use bfford on functions 
get :: Va. Ord a => Tree a —► [a] just as well. 

Can we profit from the same kind of genericity also for bj]t q 
and bffl Concentrating on bf/k q first, it seems that we cannot 
readily use the generic traverse, because template E q is based 
on a monad, not on an applicative functor. But actually every 
monad can be wrapped to form an applicative functor, and there 
are even predefined facilities for this in Control.Applicative. So 
without changing anything at all about number E q we can rewrite 
template E q as follows: 
template E q :: (Traversable k, Eq a) 

=> k a —► (k Int, IntMapEq a) 
template E q s = case runState (go s) (IntMapEq. empty, 0) 
of (s',(g,-))-> (s',g) 
where go = unwrapMonad 

o traverse (WrapMonad o numberEq) 
and then obtain a generic bidirectionalizer 
fejffEq :: Traversable k => (Va. Eq a => « a —► [a]) 

—► (Va. Eq a =t> k a —> [a] —> k a) 
simply by replacing map by fmap in the definition of bfl^q . 





And even for bff we can replace the template generation via 
s' = [0. .length s — 1] and g = IntMap .fromAscList {zip s' s) 
by a more streamlined one amenable to Traversable. Again we use 
a state monad, wrapped up as an applicative functor. In full0 
bff :: Traversable n => (Va. k a —► [a]) 

-<Va. Eq a^Ka^[a]^Ka) 

bff get = Xs v —► 
let (s', g) = template s 

h = either error id (assoc (get s') v) 
h' = IntMap. union h g 

in seq h {fmap (fromJust o flip IntMap. lookup h') s') 

template :: Traversable k => n a —> (ft Int, IntMap a) 
template s = 

case runState {go s) ([], 0) 

of (s', (Z, _)) —► (s', IntMap./romAsciisi {reverse l)) 
where go = unwrapMonad 

o traverse (WrapMonad o number) 

number :: a —> State ([(Int, a)], Int) Int 
number a = do (Z, i) <— State. get 

State.put ((*, a) : l. i + 1) 
return i 

This version is now also applicable to pet-functions with source 
data structures other than lists. For example, for the function 
flatten from the introduction we obtain: 

> bff flatten (Node (Leaf ’a’) (Leaf ’b’)) "xy" 

Node (Leaf ’x ’) (Leaf ’y’) 

Indeed, bff flatten = put 2 . 

Clearly, a similar generalization from lists to other data struc¬ 
tures is desirable for the output sides of pet-functions as well. The 
key task then is to replace assoc, assocEq, and assocord by generic 
versions that are not anymore specific to lists. Unfortunately, there 
is no predefined class like Traversable that we can simply use 
here. But there is a common core to the different a.s-soc-functions. 
Namely, they all traverse two lists in lock-step, pairing up the ele¬ 
ments found in corresponding positions, and inserting those pairs 
into some variation of integer maps. It is very natural to capture 
the first aspect, of traversing two data structures in a synchronized 
fashion and collecting pairs of corresponding elements, by a new 
type constructor class as follows: 
class Zippable k where 
tryZip :: ft a —> k fl —> Either String (re (a, ft)) 

Since such a zipping can also fail, for example if two lists have 
unequal length, we provide for potential error messages in the 
return type of tryZip. Now, for example, instances of Zippable for 
lists and for the data type Tree can be given as follows: 
instance Zippable [] where 
tryZip [] [] = Right [] 

tryZip {i : is) {b : bs) = Right (:) <*> Right {i,b) 

<*> tryZip is bs 

tryZip — Left “Update changes the length.” 

instance Zippable Tree where 
tryZip (Leaf i) (Leaf 6) = Right (Leaf (*, b)) 

tryZip (Nodefi t?) (Nodeui vi) = Right Node 

<*> tryZip ti vi 
<*> tryZip t2 V2 

tryZip — Left “Update changes the shape.” 


2 The use of reverse in the definition of template is necessary to ensure 
that IntMap .fromAscList indeed receives a list with keys in ascending 


Note that for convenient propagation of potential errors we use an 
appropriate instance of Applicative for Either String. 

Now, the a.s.soc-functions can be factorized into applications 
of tryZip followed by folding some insertion functions over the 
zipped structure containing pairs of integers and updated view 
values. By “folding”, we of course mean a generic operation not 
specific to lists, and fortunately there is already a type constructor 
class for just this purpose in the standard library Data.Foldable. 
The class method of interest here is the following one: 

Data.Foldable./oZdr :: Foldable ft =>(a—>/3—>/3)—>/3 

Using it, we get for example: 

assoc :: (Zippable ft, Foldable ft, Eq a) 

=► ft Int —► k a —► Either String (IntMap a) 
assoc = makeAssoc checklnsert IntMap. empty 

makeAssoc checklnsert empty s" v = 
either Left f {tryZip s" v) 
where / = Data.Foldable./oZdr 

{either Left o uncurry checklnsert) 
(Right empty) 

Then we can change the type of bff into 

bff :: (Traversable ft, Zippable ft', Foldable «') 

=#- (Va. k ol —+ fc' a) 

—> (Va. Eq a =>■ « a —> n’ a —> k a) 
without having to change anything at all about the function’s cur¬ 
rent definition. Analogously, with 

assocEq :: (Zippable k, Foldable ft, Eq a) 

=> ft Int —> ft a —> Either String (IntMapEq a) 
assoc Eq = makeAssoc IntMapEq. checklnsert 
IntMapEq .empty 

assocord ■■ (Zippable ft, Foldable ft, Ord a) 

=> ft Int —> ft a —> Either String (IntMapOrd a) 
assocord = makeAssoc IntMapOrd .checklnsert 
I nt M a pO rd. empty 

and without any changes to the current function definitions of bffEq 
and bfford, we get more generic types for them in the spirit of the 
final type for bff given above, that is, generalizing [a] to ft' a for 
any ft' that is an instance of both Zippable and Foldable. 

Note that instances of Foldable are already automatically deriv¬ 
able in the same fashion using Data.DeriveTH as instances of 
Traversable are, or alternatively can be obtained from Traversable 
instances using the kind of default definition seen earlier in this 
section. Thus, all the remaining effort required to make bff, bff E q , 
and bfford successfully deal with a new data type on both the in¬ 
put and output sides of jef-functions is to provide an appropri¬ 
ate Zippable instance. This could be done manually, but Hackage 
package bff-0.1 also contains an automatic deriver (contributed 
by J. Breitner) that generalizes the Zippable instances seen earlier 
in this section^] 

What about the correctness of the generic versions? Of course, 
for their specific instantiations to the case of lists our proofs as 
given previously continue to apply. For the generic case some gen¬ 
eralization effort is required. For example, Lemmas [5] and [7] need 
to be replaced by versions involving fmap instead of map, and a 
similar statement is necessary for template in order to replace the 


3 Actually, it produces slightly different definitions using an efficiency im¬ 
provement trick inspired by |Voigtlander| (2008) . Also, it became necessary 
to add a Traversable class restriction as precondition to the definition of 
class Zippable. 






use of Band® in the proof of Theorem [T] We need to derive 
generic versions of the free theorems we have used, and we need to 
replace the lemmas about ass oc-functions (i.e.. Lemmas [l]|2]|4]|5] 
and the analogues of Lemmas [4] and [5] for the Ord-setting as men¬ 
tioned in Section [5j by corresponding generic versions. Actually, 
these lemmas can now be factorized into statements about instances 
of Zippable and statements about the checklnsert- and empty- 
functions being folded over the zipped structures. We refrain here 
from exercising all this through. 

7. Discussion and Evaluation 

We have presented a new bidirectionalization technique for a wide 
range of polymorphic functions. One might wonder whether what 
we achieve is “true” bidirectionalization. After all, for a given 
forward function, we do not really obtain a backward component 
that is somehow tailored to it in the sense that it is based on a deep 
analysis of the forward function’s innards. Rather, the /.-function 
we obtain will, at runtime, observe the jet-function in forward 
mode, and draw conclusions from this kind of “simulation”. Is not 
that cheating? 

While this might first appear to be a serious objection casting 
our overall approach in doubt, we think it is ultimately unnecessary 
concern. At the end of the day, what counts is whether or not the 
obtained /.-function is extensionally the one we want and need, 
and its genesis and intensional, syntactic aspects are completely ir¬ 
relevant for this evaluation. So how good are our bff get and so on, 
under such impartial judgment? Having established the GetPut and 
PutGet laws is one step towards an answer. Moreover, even though 
we have not included the additional proofs here, also the PutPut 
law holds. That is, for every pair get/put with put = bff get, 
put = bffk q get, or put = bffo,A get, we have that if put s v and 
put (put s v) v' are defined, then 

put (put s v ) v == put s v . 

And undoability is also a given; i.e., if put s v is defined, then 
put (put s v ) (get s) == s. 

And even beyond just those base requirements, the pu/,-functions 
returned by our bidirectionalizers often do exactly The Right Thing. 
Examples for this can be seen in the introduction and throughout 
the paper, and more are easy to come by. Of course, it should not 
be expected that an automatic approach can always deliver the ab¬ 
solutely best backward component one could write by hand. For 
example, for the function halve from the introduction a slight im¬ 
provement to put 1 would be possible by weakening the condition 
length as' == n 


length as' == n || odd (length as) && length as' == n+ 1. 
Our technique does not detect this, i.e., bff halve is semantically 
equivalent to the original version of put 1 without this small im¬ 
provement. But that much comes for free, and is arguably sufficient 

Maybe a good way to think about possible application scenarios 
for our technique is to consider it as a very useful tool for rapid 
prototyping. Imagine one wants to build some system with built-in 
bidirectionality support, such as the structured document editor of 
|Hu et al.| l |2004j . Would not it be nice to have at one’s command 
much of the Haskell Prelude and polymorphic functions from other 
standard libraries, all with backward components obtained at no 
cost? Even if the automatically provided backward components are 
not perfect in each and every case, they give an initial solution and 
enable progress to be made quickly on the overall design without 
getting lost in the bidirectionality aspect. And once that design has 


solidified, it is possible to see which forward functions are actually 
going to be used, which of them are critical and did not get assigned 
a sufficiently good backward component the free and easy way, and 
then to provide fine-tuned versions for those by hand. 

For programming in the large, it would also be worthwhile to 
look at connecting our technique to the combinatory approach pi¬ 
oneered by |Foster et al.| t [2007] >. Their framework provides for sys¬ 
tematic and sound ways of assembling bigger bidirectional trans¬ 
formations from smaller ones, but naturally depends on a supply 
of correctly behaving get/put -pairs being available on the lowest 
level of granularity. Our free bidirectionalizers promise to provide 
a rich and safe source to be used in this context. It would also be 
interesting to investigate how our development relates t o recent ex- 
tensions of the combinatory approach for ordered data ^Bohannon] 

I et al.|2008b and for correctness modulo equivalence relations dFos-l 
ter et al.|2008| . 

Other pragmatic questions worth investigating include whether 
it is possible to use a similar technique to ours for deriving create- 
functions that produce a new source from a given view without 
having access to an original source, and whether it is possible to 
meaningfully augment bff, and its two variants, with additional 
parameters that steer its choice of a backward component. The 
latter may be useful, for example, when an update changes the 
shape of a view, causing the current regime to report failure. 

A somewhat secondary concern is that about the efficiency of 
the obtained put- (and potentially create-) functions. Clearly, a 
purely semantic approach like ours here cannot in general hope 
to produce as efficient backward components as a more syntac¬ 
tic, but also more restricted, approach might achieve. After all, de¬ 
tached from the realm of syntax, no intensional knowledge about 
the je£-function’s underlying algorithm can be gained and thus 
used. But this does not impair the prototyping scenario sketched 
above. And dumping premature optimization, the safety and pro¬ 
grammer (rather than program) productivity boon offered by free 
bidirectionalization may often be more essential in practice than 
efficiency differences that may only show up at rather large scales 
of data. 

That said, there is room for improving the efficiency of pul- 
functions as obtained by our technique. For one thing, the variations 
of integer maps used are currently implemented rather naively. 
Some data structure and algorithm engineering would likely have a 
beneficial impact here. Also, even though our bidirectionalizers are, 
by design, ignorant of the definition of the je/,-function provided 
as argument, nothing stops us, or a compiler, from inlining that 
function definition in a particular application like bff get for a 
concrete je/,-function. Then, the door is open to applying any of 
the program specialization and fusion methods that abound in the 
field of functional languages. In combination with rules about the 
integer map interface functions, it might even be possible in some 
cases to thus transform the automatically obtained put-functions 
into ones with efficiency close to hand-coded versions. 

And yet, just how bad is the current performance? To evaluate 
this, we have run a few simple experiments on a 2.2 GHz AMD 
Opteron 248 processor (core) with 2GB memory. Every experiment 
consists of comparing the efficiency of one of the hand-coded 
pwi-functions from the introduction to that of the corresponding 
automatically obtained version, on input data structures of varying 
sizes and with views that actually represent permitted updates. 
The elements contained in source and view data structures are 
integers, so that each equality test on them takes constant time only. 
To make asymptotic behavior more apparent, runtimes are plotted 
normalized through division by input size. The results can be seen 
in Figures|4j|7] 











Figure 4. Evaluation of put x vs. bJJ halve. 


Measurements "flatten, left-leaning trees, normalized" 



Figure 5. Evaluation of put 2 vs. bJJ flatten, on nasty input. 





Figure 6. Evaluation of put 2 vs. bff flatten, on nice input. 


Measurements "rmdups, all elements different, normalized" 



Figure 7. Evaluation of put 3 vs. bflkq rmdups. 
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A. Proof of Theorem [2] 

Let get :: Vq.[q] —> [a], let r be a type that is an instance of Eq, 
and let v, s :: [r]. If bff get s v is defined, then we necessarily have 


bff get s v = map f s', 

Right h = assoc (get s') v (7) 

h' = IntMap .union h g (8) 

/ = fromJust o flip IntMap. lookup h' (9) 

(and the values of s' and g are unimportant in what follows). Thus, 
by the free theorem mentioned in the proof of Theorem[l] 

get {bff get sv) = map f (get s'). (10) 

By 0 and Lemma[2]we have 

map ( flip IntMap.lookup h) {get s') = map Just v . (11) 


In particular, for every i in get s', we have IntMap. lookup i h = 
Just b for some b :: r. But then by {8} and the specifications of 
IntMap. union and IntMap. lookup, 

map (flip IntMap. lookup h') (get s') 
map (flip IntMap. lookup h) {get s'). 

Together with {9}, the well-known anti-fusion law map (/1 0 J'2 ) = 
map fi o mapj2, and 0 , this implies 

map f (get s') == map fromJust (map Just v) , 
which gives 

get {bff get s r) == v 

by {To). 


B. Proof of Theorem [3] 

Let get :: Va. Eq a =>■ [a] —> [a], let r be a type that is an instance 
of Eq, and let s :: [r]. By the function definition for bf/fq we have 


bffEq get s {get s) 

(map (fromJust o flip IntMapEq .lookup h') s'), 


( 12 ) 


where: 

{s', g) = templateEq s (13) 

h = either error id {assocEq {get s') {get s)) (14) 

h' = either error id (IntMapEq. union h g). (15) 

By {73} and Lemma[3] we have 

map {flip IntMapEq .lookup g) s' == map Just s, (16) 

as well as that 

• for every i :: Int not in s', IntMapEq.loofatp i g = Nothing, 
and that 

• flip IntMapEq. lookup g is injective on s'. 

Consequently, setting 

/ = fromJust o flip IntMapEq. lookup g, 


map f s' == s (18) 

and that / is injective on s'. By Lemma[6] this gives 
map f {get s') == get s 

and that every i in get s' is also in s'. Together with {l4} and 
Lemma [4] we can conclude that h is defined and that for every 
i :: Int, 

IntMapEq. lookup i h == if elem i {get s') then Just (/ i) 
else Nothing. 

On the other hand, we have by ffTj i, and the fact (derived 
above) that for every i :: Int not in s', IntMapEq. lookup i g = 
Nothing, that for every i :: Int, 

IntMapEq. lookup i g = if elem i s' then Just (/ i) 
else Nothing. 

Hence, by fi~5} . the injectivity of flip IntMapEq. lookup g on s' 
(derived above), the fact (also derived above) that every i in get s' 
is also in s', and the specification of IntMapEq. union, we have 
that h! is defined and that for every i in s', 

IntMapEq. lookup i h' =« Just (/ i). 

Together with (l2| and (T8) , this gives 

&ifEq get s {get s) == s. 

C. Proof of Theorem [4] 

Let get :: Va. Eq a =>■ [a] —> [a], let r be a type that is an 
instance of Eq, and let v, s :: [t]. If bjjtq get s v is defined, then 
we necessarily have 

bffi Eq get sv= map f s', (19) 

{s', g) = templateEq s (20) 

Right h = assocEq {get s') v (21) 

Right h' = IntMapEq. union h g (22) 

/ m fromJust o flip IntMapEq.Zoofatp h'. (23) 

By |2(j| and Lemma [5] we have that for every i in s', it holds 
IntMapEq .lookup i g = Just a for some a :: r. Moreover, by {27} 
and Lemma[5]we have 

map {flip IntMapEq. lookup h) {get s') == map Just v, (24) 
as well as that 

• for every i :: Int not in get s', IntMapEq. lookup i h = 
Nothing, and that 

• flip IntMapEq. lookup h is injective on get s'. 

Putting all these facts tog ether with {22}, the specification of 
IntMapEq. union, and {23} , we get that / is injective on s'. Thus, 
by {19} and Lemma[6] 

get {bjfEq get s v) == map f {get s ). (25) 

The remainder of the proof is analogous to the second half of that 
for Theorem [2] in Appendix [A] where now {22}-{25} take the roles 

0f{8}-{TT}. 


(17) 


